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Deprecation of ICMP Source Quench Messages 


Abstract 
This document formally deprecates the use of ICMP Source Quench 
messages by transport protocols, formally updating RFC 792, RFC 1122, 
and RFC 1812. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6633. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The ICMP specification [RFC0792] defined the ICMP Source Quench 
message (type 4, code 0), which was meant as a mechanism for 
congestion control. ICMP Source Quench has been known to be an 
ineffective (and unfair) antidote for congestion, and generation of 
ICMP Source Quench messages by routers has been formally deprecated 
by [RFC1812] since 1995. However, reaction to ICMP Source Quench 
messages in transport protocols has never been formally deprecated. 


This document formally deprecates reaction to ICMP Source Quench 
messages by transport protocols such as TCP [RFC0793], formally 
updating [RFC0O792], [RFC1122], and [RFC1812]. Additionally, it 
provides a recommendation against the implementation of [RFC1016]. 
The rationale for these specification updates is as follows: 


o Processing of ICMP Source Quench messages by routers has been 
deprecated for nearly 17 years [RFC1812]. 


o Virtually all popular host implementations have removed support 
for ICMP Source Quench messages since (at least) 2005 [RFC5927]. 


o Widespread deployment of ICMP filtering makes it impossible to 
rely on ICMP Source Quench messages for congestion control. 


o The IETF has moved away from ICMP Source Quench messages for 
congestion control (e.g., note the development of Explicit 
Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6 
[RFC4443] does not even specify a Source Quench message). 
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ICMP Source Quench messages are not normally seen in the 
deployed Internet and were considered rare at least as far back 
as 1994 [Floyd1994]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. ICMP Source Quench Messages 


The ICMP specification [RFC0792] defined the ICMP Source Quench 
message (type 4, code 0), which was meant to provide a mechanism for 
congestion control. The Host Requirements RFC [RFC1122] stated in 
Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages 
by slowing transmission on the connection, and further added that the 
RECOMMENDED procedure was to put the corresponding connection in the 
slow-start phase of TCP’s congestion control algorithm [RFC5681]. 


[RFC1812] noted that research suggested that ICMP Source Quench was 
an ineffective (and unfair) antidote for congestion, and formally 
deprecated the generation of ICMP Source Quench messages by routers, 
stating that routers SHOULD NOT send ICMP Source Quench messages in 
response to congestion. 


[RFC5927] discussed the use of ICMP Source Quench messages for 
performing "blind throughput-reduction" attacks, and noted that most 
TCP implementations silently ignore ICMP Source Quench messages. 


We note that TCP implements its own congestion control mechanisms 
[RFC5681] [RFC3168], which do not depend on ICMP Source Quench 


messages. 


It is interesting to note that ICMPv6é [RFC4443] does not specify a 
Source Quench message. 


3. Updating RFC 1122 
This document hereby updates Section 3.2.2.3 of [RFC1122] as follows: 


A host MUST NOT send ICMP Source Quench messages. 


If a Source Quench message is received, the IP layer MAY silently 
discard it. 


Section 4.2.3.9 of [RFC1122] is updated as follows: 


TCP MUST silently discard any received ICMP Source Quench 
messages. 
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The consensus of the TSV WG was that there are no valid reasons for a 
host to generate or react to an ICMP Source Quench message in the 
current Internet. The recommendation that a sender "MUST NOT" send 
an ICMP Source Quench message is because there is no known valid 
reason for a host to generate this message. The only known impact of 
a sender ignoring this requirement is that it may necessarily consume 
network and endpoint resources. Discarding ICMP Source Quench 
messages at the Internet layer (rather than at the transport layer) 
is a performance optimization that is permitted by this update. 


4. Updating RFC 1812 


This document hereby updates Section 4.3.3.3 of [RFC1812] as follows: 


A router MUST ignore any ICMP Source Quench messages it receives. 


The consensus of the TSV WG was that there are no valid reasons for a 
router to react to ICMP Source Quench messages in the current 
Internet. 


5. Clarification for UDP, SCTP, and DCCP 
UDP [RFC0768] did not explicitly specify support for ICMP Source 


Quench messages. Hereby, we clarify that UDP endpoints MUST silently 
discard received ICMP Source Quench messages. 


It is understood that SCTP [RFC4960] and DCCP [RFC4340] did not 
specify support for processing received ICMP Source Quench messages. 
Hereby, we clarify that DCCP and SCTP endpoints MUST silently discard 
received ICMP Source Quench messages. 


6. General Advice to Transport Protocols 


If a Source Quench message is received by any other transport- 
protocol instance, it MUST be silently ignored. 


The TSV WG is not aware of any mechanism that requires processing of 
these messages and therefore expects other transports to follow the 
recommendations in Section 3. Note that since generation of ICMP 
Source Quench messages has been deprecated for many years, and since 
this document additionally deprecates reaction to ICMP Source Quench 
messages by IETF-specified transports, future applications cannot 
expect to receive these messages. 
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7. 


10. 


Recommendation Regarding RFC 1016 


[RFC1016] describes an experimental approach to the handling of ICMP 
Source Quench messages in hosts that was considered in 1987. Even 
though RFC 1016 has never been on the IETF Standards Track, for 
clarity and avoidance of doubt we note that the approach described in 
[RFC1016] MUST NOT be implemented. 


Security Considerations 


ICMP Source Quench messages could be leveraged for performing blind 
throughput-reduction attacks against TCP and similar protocols. This 
attack vector, along with possible countermeasures, has been 
discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently 
ignoring ICMP Source Quench messages, as specified in this document, 
eliminates the aforementioned attack vector. 


For current TCP implementations, receipt of an ICMP Source Quench 
message should not result in security issues because, as noted in 
[RFC5927] and [CPNI-TCP], virtually all current versions of popular 
TCP implementations already silently ignore ICMP Source Quench 
messages. This is also the case for SCTP and DCCP implementations. 


Hosts, security gateways, and firewalls MUST silently discard 
received ICMP Source Quench packets and SHOULD log such drops as a 
security fault with at least minimal details (IP Source Address, IP 
Destination Address, ICMP message type, and date/time the packet was 
seen). 


We note that security devices such as the Snort Network Intrusion 
Detection System (NIDS) have logged ICMP Source Quench messages as 
such for more than ten years [Anderson2002]. 


IANA Considerations 


IANA has marked ICMP type 4 (Source Quench) as "Deprecated" in the 
ICMP Parameters registry [ICMPPARREG] with a reference to this 
document. 
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Appendix A. Survey of Support of ICMP Source Quench in Some Popular 
TCP/IP Implementations 


A large number of implementations completely ignore ICMP Source 
Quench messages meant for TCP connections. This behavior has been 
implemented in, at least, Linux [Linux] since 2004, and in FreeBSD 
[FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since 
2005. Additionally, OpenSolaris [OpenSolaris] has always shipped 
with support for ICMP Source Quench messages disabled. 
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